1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer-readable code for delegating authority in a public key authentication environment from a client to a server machine or process, in order that the server machine or process can then securely access resources and securely perform tasks on behalf of the client. This technique is defined in a manner where the client does not directly access the private key system.
2. Description of the Related Art
Public key authentication of users is becoming increasingly common, especially in Internet environments for electronic commerce. The Internet was originally designed with the academic and scientific communities in mind, and it was assumed that the users of those communities would be working in a non-adversarial, cooperative manner. Thus, the Internet was designed without security features inherent in the network. As the Internet expands out into the public sector, commercial aspects are becoming increasingly common, giving rise for the need to protect assets and resources by providing security measures.
With the need for more secure communications, different types of security systems and measures have evolved over time. Each system has attempted to address the security issues for protecting communications in an unsecure environment (such as the Internet). One aspect of secure communications is the ability to ensure that a communication received has actually come from the person believed to have generated it and not from someone impersonating that person on the network. This is known as xe2x80x9cauthenticationxe2x80x9d.
One of the oldest and most common security systems today is what is known as a xe2x80x9cprivate keyxe2x80x9d security system. Private key systems involve two users, both of whom have a shared secret (or private) key for encrypting and decrypting information passed between them over a network. Before communications can occur, the two users must communicate in some secure manner to agree on this private key to ensure the key is known only to the two users. An example of a private key security system is the Kerberos system developed by the Massachusetts Institute of Technology. Private key systems have a number of drawbacks in an open network environment such as the Internet, however, where users will conduct all communications over the open network environment and do not need or want the added overhead and expense of a secure means of exchanging key information before secure network communications occur.
To address the limitations of private key systems, security systems known as xe2x80x9cpublic keyxe2x80x9d systems evolved. In a public key system, a user has a key pair that consists of a private key and a public key, both keys being used to encrypt and decrypt messages. The private key is never to be divulged or used by anyone but the owner. The public key, on the other hand, is available to anyone who needs to use it. As an example of using the key pair for encrypting a message, the originator of a message encrypts the message using the receiver""s public key. The receiver then decrypts the message with his private key. To use a key pair for authentication, the message originator digitally signs the message (or a digest there of) using his own private key. The receiver decrypts the digital signature using the sender""s public key.
Today, public key systems do not provide a delegation model whereby a server machine or process can be authorized to act on behalf of a user. A delegation model would allow, for example, a user to authorize a server or process to have the same access and privileges for protected resources as that user has. This would allow the server machine or process to act on behalf of the user, without requiring ongoing involvement of the user.
The Kerberos system includes a delegation model that allows a user to obtain a Kerberos ticket for a particular resource. This ticket can then be delivered to a server machine or process for use by that server machine or process on behalf of the user. The Kerberos system alone, however, is not appropriate for a public network environment such as the Internet because it requires all administrators of user identities to have equal access to the network resources protected by Kerberos. In addition, Kerberos is a private key system. This means the Kerberos server would need to securely maintain the private key of each user with whom it exchanges secure messages. This is an unrealistic administrative burden in a public access environment.
Request for Comments (xe2x80x9cRFCxe2x80x9d) 68.4, entitled xe2x80x9cIntegration of DCE and Public Key Technologiesxe2x80x9d, proposes one solution to this problem, where a client communicates directly with a Kerberos server using public key authentication. The client obtains a ticket-granting ticket (TGT) from the Kerberos server, and then uses this TGT to obtain additional tickets from the Kerberos server as needed for particular units of work. Such tickets are sent from the client to the delegated server, so that this delegated server can perform the work on the client""s behalf. This approach has a number of drawbacks, however. First, the client software must be changed to support communication with the Kerberos server. Second, users and clients outside the enterprise must be able to access the Kerberos server directly with this approach. Thus, this technique makes the Kerberos server, which is the critical point in Kerberos security, vulnerable to access from the outside. Third, the TGT actually passes outside the enterprise with this approach, creating some security exposures. Fourth, firewalls must be modified or configured to permit access to the Kerberos server from outside the enterprise. While RFC 68.4 may be beneficial within an enterprise, these drawbacks make it a less-than-optimal solution for Internet and extranet commerce. (The RFC 68.4 specification is available on the World Wide Web at http://www.opengroup.org/dce/tech/pki/index.html.)
Accordingly, what is needed is a technique for providing delegation of authority to a server machine or process in a public key environment without a client directly accessing a private key authentication system.
An object of the present invention is to provide a technique whereby a client delegates authority to a server machine or process.
Another object of the present invention is to provide this technique whereby a private key authentication system is used to obtain client credentials for use in a public key system.
A further object of the present invention is to provide this technique whereby the client credentials are used to define the resource access for which this client is authorized.
Another object of the present invention is to provide a technique whereby access to protected resources by a server machine or process on behalf of a client in a public key environment is controlled using information obtained from a private key system.
A further object of the present invention is to provide this delegation technique whereby the private key system is the Kerberos system.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a method, system, and computer-readable code for use in a computing environment having a connection to a network, for enabling a server to perform tasks on behalf of a client in a public key environment using authorization obtained from a private key system (PRKS) without the client directly accessing the PRKS. This technique comprises: obtaining the authorization for the client from the PRKS using public key authentication; delegating the obtained authorization to the server; performing, by the server, the requested task using the delegated authorization; and returning a result of the performing from the server to the client.
In a first aspect, the obtaining further comprises: authenticating, in the PRKS, an identification of the client; and comparing, in the PRKS, the identification of the client to a stored mapping between a plurality of client identifications and client access privileges. In this aspect, the delegating further comprises: sending a session credential from the PRKS to the server when the comparing successfully locates the identification of the client; sending, responsive to receiving a request from the client, the session credential and a request for the delegated authorization from the server to the PRKS; checking stored policies in the PRKS, responsive to receiving the session credential and the request for delegated authorization; and sending the requested delegated authorization from the PRKS to the server when the checking has a successful outcome.
In a second aspect, this technique further comprises authenticating the PRKS in the client, and the obtaining further comprises: authenticating an identification of the client in the PRKS; and comparing, in the PRKS, the identification of the client to a stored mapping between a plurality of client identifications and client access privileges. In this aspect, the delegating further comprises: sending a session credential and, if message encryption is to be used, a session key from the PRKS to the server when the comparing successfully locates the identification of the client; sending, responsive to a request from the client, the session credential and a request for the delegated authorization from the server to the PRKS; checking stored policies in the PRKS, responsive to receiving the session credential and the request for delegated authorization; and sending the requested delegated authorization from the PRKS to the server when the checking has a successful outcome.
In a third aspect, the obtaining is invoked in response to receiving a request from the client, and further comprises: determining, in the server, one more authorization privileges that are required to perform the requested task; and requesting the authorization privileges from the client. In this aspect, the delegating is invoked in response to receiving the request for authorization privileges, and further comprises: verifying, in the client, the requested authorization privileges; sending a client certificate and a signed request for the requested authorization privileges from the client to the server; forwarding the client certificate and the signed request from the server to the PRKS; comparing, in the PRKS, an identification of the client from the client certificate to a stored mapping between a plurality of client identifications and client access privileges; checking, in the PRKS, stored delegation privileges to determine whether the client authorizes the server to receive the requested authorization privileges; and sending the requested authorization privileges from the PRKS to the server when the checking step has a successful outcome.
In a fourth aspect, this technique further comprises authenticating the PRKS in the client, and: the obtaining is invoked in response to a request from the client, and further comprises: forwarding the request from the server to the PRKS; and determining, in the PRKS, one or more authorization privileges which are required for performing the request. In this aspect, the delegating further comprises sending a session key and the requested authorization privileges from the PRKS to the server.
In each of these aspects, the requested authorization privileges may be represented by one or more authorization tickets. The PRKS may be a system known as xe2x80x9cthe Kerberos systemxe2x80x9d.